Credit cards (and debit cards that leverage credit card processing networks) are a widely used financial instrument. Accordingly, in order to appeal to a broad base of potential buyers, it is advantageous for merchants to be able to receive payment for goods or services utilizing a buyer's credit card. In order to receive credit card payments, merchants are typically required to establish so-called merchant bank accounts with acquiring banks, into which a credit card fund transfer can credit funds received in payment of goods or services. The establishment of a merchant bank account is not a trivial undertaking. Approval of a merchant bank account from an acquiring bank may take weeks to receive. Further, there are numerous charges associated with the maintenance and utilization of such merchant bank accounts. For example, an acquiring financial institution (e.g., a bank), with which the merchant bank account is established, typically charges discount rates (e.g., 2%-3% of a transaction total) to settle transactions. There are further reserve costs that the acquiring financial institution may hold back to cover contested charges and charge back fees.
Credit card payments to a merchant bank account may furthermore be merchant-initiated, as is the typical case in a “bricks-and-mortar” purchase scenario, or may be buyer-initiated where the transaction occurs in an online environment. A brief discussion is provided below regarding the processing of credit card transactions that are both merchant-initiated and buyer-initiated, within different environmental contexts.
FIG. 1 is a diagrammatic representation of a prior art credit card transaction processing scheme in the traditional “bricks-and-mortar” environment, where a buyer 10 is physically present at a seller location 12, and accordingly able to present a credit card to the seller 14. In this scenario, in order to communicate the buyer's credit card information to a credit card processing system, the seller 14 typically maintains an on-site Point Of Sale (POS) terminal 16. The seller 14 swipes the buyer's credit card through the POS terminal 16, which then provides the relevant credit card information via a dialup connection, established over a Plain Old Telephone Service (POTS) network 18, to a payment gateway 20. The payment gateway 20 acts as interface between external networks (e.g., the POTS network 18 or the Internet) and a proprietary and secure network over which the various components of a credit card processing system may communicate.
The funds transfer request that is issued from the POS terminal 16, in addition to including the credit card information of the buyer, also includes (1) a merchant identification number, identifying the seller's-merchant bank account at an acquiring financial institution, and (2) a terminal identification number identifying the specific POS terminal 16. The terminal identification number is utilized to distinguish between multiple POS terminals 16 that may be operated by the seller 14, for example at various locations.
From the payment gateway 20, the funds transfer request is communicated to an authorization system 22 for the authorization phase. The authorization system 22 communicates pertinent details of the funds transfer request to an issuing bank 24, at which the buyer's credit card account 26 is maintained. The issuing bank 24 will then make a determination as to whether the buyer's credit card is valid and whether the buyer's credit card has the capacity to absorb the relevant charge. The authorization system 22 may also, in certain circumstances, communicate pertinent details of the funds transferred to an authorization agent 28 (e.g. VISA, MASTERCARD, AMERICAN EXPRESS, etc.), which is distinct at the issuing bank 24, to determine whether the relevant credit card has been reported stolen or the authorization agent is aware of any other deficiencies. Having received affirmative authorizations from the issuing bank 24 and/or the authorization agent 28, the authorization system 22 will, via the payment gateway 20 and the POTS network 18, communicate the authorization back to the POS terminal 16, this authorization then being displayed to the seller. Responsive to the authorization, the POS terminal 16 will also typically print a receipt for signature by the buyer 10.
Having now completed the authorization phase of a payment processing operation, a settlement phase is then initiated. Specifically, the funds transfer request, and the relevant authorization, are communicated to a settlement system 30. The settlement system 30 operates to transfer authorized funds for a transaction from the buyer's credit card account 26 to the seller's merchant bank account 34. A settlement may be performed in real-time, but is more typically performed as part of a batch operation once a day. The settlement process requires the settlement system 30 to communicate details of the funds transfer, including the amount, and merchant identification information to both the issuing bank and the acquiring bank. At the issuing bank 24, the buyer's credit card account 26 is debited with the relevant charge, and a record created in the buyer's credit card account indicating, inter alia, so-called “merchant of record” information, this information identifying the seller. At an acquiring bank 32, the seller's merchant bank account 34 is credited with the relevant amount. The seller's merchant bank account 34 is identified utilizing the merchant identifier number communicated from the POS terminal 16. At the acquiring bank 32, the relevant funds may then be transferred from the seller's merchant bank account 34 to a seller's check account 36.
It will be noted that the seller's merchant bank account 34 is indicated in FIG. 1 as being “present” merchant bank account, indicating that the merchant bank account 34 is associated with a physical POS terminal. Acquiring banks 32 may differentiate between a “present” merchant bank account, which receives payments where the buyer is “present” at a seller location and accordingly able to physically present a credit card, and a so-called “not-present” merchant bank account, for which the credit card information of the buyer is not received by the physical presentation of a credit card to the seller. The reason for the differentiation between “present” and “not-present” merchant bank accounts is that the likelihood of fraud against “not-present” merchant bank accounts is higher, and accordingly the charges levied by the acquiring bank 32 for a “not-present” merchant bank accounts are typically higher than those levied for “present” merchant bank accounts.
Continuing with merchant-initiated credit card payment transactions, FIG. 2 illustrates a credit card processing system to enable merchant-initiated credit card payment transactions when the buyer 10 is “not-present” at a seller location, and accordingly unable to physically present a credit card to the seller 14 to swipe through a POS terminal 16. FIG. 2 illustrates that the buyer communicates order and credit card information 40 to the seller 14 verbally during a telephone call established between the buyer 10 and the seller 14. Of course, the order and credit card information 40 can be communicated utilizing any one of a number of other mediums (e.g., fax, mail, email, web, phone etc.) to the seller 14. In any event, the seller 14 receives the buyer's 10 credit card information without being physically presented the credit card, and accordingly is unable to verify the signature on the credit card against the buyer's 10 signature. In this case, as the seller 14 does not have the physical card, an alternative mechanism is required in order to enable the merchant to initiate a credit card payment transaction, utilizing the received credit card information.
Accordingly, a seller computer system 42, to which the seller 14 has access, is shown to host and execute a virtual POS terminal application 44, into which the seller 14 can input the buyer's 10 credit card information. The seller computer system 42 is coupled by a network 46 (e.g., the Internet) to a virtual POS terminal service provider 48, which in turn processes and forwards the credit card information to a payment gateway 20. From the payment gateway 20, payment processing (i.e., the authorization and settlement phases) is substantially similar to that described above with reference to FIG. 1. One difference will be that the seller merchant bank account 34, maintained by the acquiring bank 32, would be flagged as a “not-present” merchant bank account in this scenario.
FIG. 3 illustrates a typical prior art credit card processing system that enables such buyer-initiated payment transactions (as opposed to the merchant-initiated transactions described above). In FIG. 3, the seller 14 operates a seller website (or marketplace) 50 that hosts a payment application 52 accessible, via a network 54 (e.g., the Internet) by a browser 56 executing on a client machine 58. The seller website 50 may provide a catalogue of items for user purchase, and the payment application 52 may provide a “check out” process to complete payment for items selected for purchase by a buyer 10. Accordingly, the payment application 52 may solicit credit card, and other personal information, from the buyer 10, via the browser 56, and communicate this information, again via the network 54, to the payment gateway 20. In certain applications, the payment application 52 may be hosted on a server external to the seller website 50, in which case the browser 56 may be redirected to a website of a payment service, which itself hosts the payment application 52, in order to process payment for purchases made via the seller website 50.
Once the payment gateway 20 receives the buyer's 10 credit card information, the downstream processing of the transaction is substantially similar to that described above with reference to FIG. 1. Again, it will be noted that, for this scenario, the seller merchant bank account 34 is designated as a “not-present” merchant bank account.